Thanks Simon. I agree that this should move away from the Boost.Python wrapper path.

I checked the currently visible branches on diffpy/diffpy.srreal. I see migration-nano, but it still appears to use the existing Boost.Python binding code and I do not see nanobind usage there. Could you confirm the exact nano/nanobind branch or PR that I should use as the base?

Once the correct base is clear, I will prepare a clean PDF3DCalculator binding branch against that nanobind base, rather than continuing to extend the current Boost.Python wrapper in this PR. I will also keep this dependent on the companion libdiffpy PDF3DCalculator PR.

Thanks Simon. I agree that this should move away from the Boost.Python wrapper path.

I checked the currently visible branches on diffpy/diffpy.srreal. I see migration-nano, but it still appears to use the existing Boost.Python binding code and I do not see nanobind usage there. Could you confirm the exact nano/nanobind branch or PR that I should use as the base?

Once the correct base is clear, I will prepare a clean PDF3DCalculator binding branch against that nanobind base, rather than continuing to extend the current Boost.Python wrapper in this PR. I will also keep this dependent on the companion libdiffpy PDF3DCalculator PR.

These edits are not merged yet, they are in #86 . It would be a help if you could review them and look for any issues. Also, that PR is showing up as a draft. I am not sure why. Perhaps you could work with the team to help us get to a point where we can merge this safely, then you can use the migration-nano as the base branch.

@joeseaer I gave a quick look at #86 and it is a bit of a dirty PR so we will redo it, but please could you look at the code updates over there and see if you see any issues so when we redo it we can incorporate any improvements that you can see.

@SYMSCAE please can you communicate with @joeseaer who is writing a new 3D PDF calculator.

@joeseaer I think we discussed the name for this class with @dragonyanglong and thought PDF3D is better than 3DPDF (or ThreeDPDF to make it work) but let's think about it a bit so we can make the naming more standard across the project. For example, we now have DebyePDFcalculator and not PDFDebyeCalculator and this breaks that. Another thought is that moving forward we hope there will be many calculators for different things like a XANES calculator or something. If we want to standardize naming, we may want to standardize to SignalMethodCalculator or something like that. So all the debye PDF calculator would be PDFDebyeCalculator or more strictly PdfDebyeCalculator. In your case, in this scenario, I think you are calculating something different which is 3DPDF which is different from PDF, so 3DPDFCalculator would be more logical.

I had a quick conversation with Gemini and I think the best is to move to SignalMethodCalculator as our standard. This means that we may want to call this ThreedpdfCalculator (to be strict) and ThreedPdfCalculator or ThreedPDFCalculatororThreeDPDFCalculator`. Any thoughts? The reason for this standardization is so things can scale well to other signals and methods. We hope that there will be many!